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(54) Computer system with network interface 



(57) The web sharing manager 160 of a receiving 
sharing client 150A receives duplicated events (e.g. 
browser requests) and messages from the web sharing 
manager of a source sharing client 150A that causes 
the browser 1 30B of the receiving sharing client to exe- 
cute the duplicate event/message so that the browsers 



130A, 130B of the source and receiving sharing client 
computer system(s) process the same events/messag- 
es. Because events/messages, including control and in- 
formation locations (addresses), are shared between 
the source and receiving sharing client(s), the same web 
page is simultaneously displayed and controlled, i.e. 
shared, on all of the sharing client(s). 
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Description 

The present invention relates to computers having 
a network interlace, to allow data sharing across the net- 
work. The invention is particularly applicable to multiple 
users sharing the same HTML page on the Internet. 

The Internet comprises multiple interconnected 
computer networks so that any computer on a given net- 
work can communicate with one or more computers on 
any other given network. A gateway computer is a com- 
puter which interconnects two networks and passes da- 
ta from one network to the other(s). 

All the computers on the Internet communicate 
through certain communication protocols, i.e. Internet 
Protocol (IP). Most applications use Transmission Con- 
trol Protocol (TCP) abng with the Internet Protocol. 
Therefore the Internet is also referred as a TCP/IP net- 
work. Any computer connected to the Internet is identi- 
fied by a unique Internet address. 

The Internet uses a well known packet-switching 
technology to route information. On the Internet, the da- 
ta is transferred through packets (also called IP packets) 
with an address. The speed and reliability of transmis- 
sion of the IP packets rely on the data traffic and routing. 
For an example of internetworking communications, see 
U.S. Patent number 5,371 ,852 to Attanasio et al. entitled 
"Method and Apparatus for Making a Cluster of Com- 
puters Appear as a Single Host on a Network" issued 
December 6, 1994. 

Some common Internet applications include Elec- 
tronic Mail, FTP, Telnet and Network news among oth- 
ers. Internet communication protocols and applications 
are well known. 

The World Wide Web (i.e. WWW or Web) is an in- 
formation service system which is based on the Internet. 
The WWW uses Hypertext and client/server technology. 
Hypertext is a method of organizing and presenting in- 
formation such that any data object in a hypertext file 
can have links to other hypertext files or data objects. 
For example, while viewing a hypertext page, a user can 
select a word which has links. This may bring the user 
to another hypertext file which contains more text and 
pictures explaining this word. (The new file may also 
have more links to other hypertext files and so forth.) 

Currently the hypertext file is organized using a Hy- 
perText Markup Language (HTML). A hypertext data ob- 
ject can be almost any information medium such as text, 
image, sound, movie or even a piece of an executable 
computer program. Any hypertext file on the Web is 
uniquely identified by its Universal Resource Locator 
(URL). 

The Web client or client (commonly a computer ex- 
ecuting a program called a browser) is essentially a hy- 
pertext reader which communicates with a Web server 
through certain data transfer protocols, such as a Hy- 
pertext Transfer Protocol (HTTP). The client can re- 
quest a hypertext file with its URL and display the file on 
a graphical user interface (GUI). This display is called a 
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web page. The client can also pass certain data back to 
the server and can invoke the Common Gateway Inter- 
face (CGI) programs on the server computer to conduct 
certain tasks. Browsers are commonly known - one pop- 
s ular browser is Netscape Navigator ("Netscape Naviga- 
tor" is a trademark of the Netscape Communications 
Corporation). 

Using the world wide connections of the Internet, 
the WWW allows a user, being anywhere on the Inter- 
ne net, to post any hypertext file on the WWW and fetch 
any hypertext file from all over the world as conveniently 
as using a local hard disk. This gives the user a tremen- 
dous power to acquire information and also turns the 
Internet into a hypermedia global database, i.e. the in- 
15 formation superhighway. The Internet and the WWW 
have been growing explosively over the past few years. 
Businesses have also seen the great potential of using 
the Internet and WWW as the new generation of world- 
wide communication infrastructure to approach a mas- 
sive consumer market. 

Even though the Web technology gives a user great 
ability to access/send all kinds of information anywhere 
in the world, currently users basically have to "travel 
alone," i.e. users can not present the same information 
on their web page as other users who are concurrently 
browsing. 

Individual users can run a browser to view web pag- 
es. The web pages are in the form of an HTML format. 
However, the browser used by each individual can not 
control other browsers in terms of what page another 
browser is seeing. 

Currently, if a first person wants to share a web page 
with a second user, i.e. "collaborate", the first and sec- 
ond users have to use another communication means, 
e.g. a telephone, to coordinate their collaboration. 

For example, they must coordinate the sharing of 
the page by sharing the address of the page, selecting 
entries ol the page, communicating movement on the 
page, communicating movements to and from other lo- 
cations, etc. This coordination requires that the first and 
second user exchange a great deal of information very 
frequently with one another over the other communica- 
tion means in order to coordinate the browsing. 

The prior art does not permit any automatic com- 
munication and/or control directly between two or more 
browsers used by two or more respective users on the 
internet. Any collaboration, e.g. page sharing, done by 
the prior art, requires the users to communicate through 
a communication line other than through the browser. 
Collaboration requires the facility and the expense of a 
second communication means. The prior art collabora- 
tions often require repeated, and error prone, exchang- 
es of information over the second communication 
means. 

Further, the users can not have "simultaneous col- 
laborations' on a given page. For example, the first user 
can move to a different location on the page or move to 
a different page without the second user knowing it. Un- 
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less the first and second users communicate over a sep- 
arate communication link, the first user will not be aware 
of what the second user is seeing/doing on their respec- 
tive pages, and vice versa. For example, a bank cus- 
tomer looking at a bank HTML home page can not ask 5 
a question and/or receive an answer of (from) a bank 
clerk or agent unless the communication between the 
customer and the bank agent is done by another com- 
munication method, e.g. phone. The agent (customer) 
does not have control over what page the customer 
(agent) sees. 

The prior art does not permit multiple users to col- 
laborate and/or share information on a common web si- 
multaneously. That is, multiple users do not automati- 
cally see the same page (and changes to the page) at 
the same time. Multiple users also do not share control 
of the information on the web. For example, they do not 
see changes at the same time and/or do not see trans- 
fers to other pages at the same time. 

Accordingly, the invention provides a computer sys- 
tem having one or more memories, one or more central 
processing units, one or more displays, one or more us- 
er input devices, an operating system, and a network 
interface with a network protocol for communicating to 
a network, the network connected to one or more serv- 
ers and one or more shared computers, the computer 
further comprising: 

a browser for requesting one or more pages from 
one or more of the servers by sending one or more 
browser requests though the network interface and 
over the network to the server and the browser re- 
ceiving from the server one or more of the request- 
ed pages sent over the network through the network 
interface; 

one or more redirectors capable of recreating as re- 
directed browser requests one or more of the 
browser requests necessary to create a web page 
on the display; and 

a web sharing manager connected to the network 
interface, for receiving the redirected browser re- 
quests, and for sending the redirected browser re- 
quests over the network to one or more of the 
shared computers. 

In a preferred embodiment, the browser is capable 
of generating and processing one or more events and 
said operating system is capable of processing one or 
more messages, and said system further comprises a 
queue for stacking one or more queued entries, one or 
more of the queued entries each containing one of the 
messages, and one or more of the queued entries each 
containing one of the events; 

and wherein said one or more redirectors are ca- 
pable of monitoring and recreating as redirected queued 
entries one or more of the queued entries, and said web 
sharing manager is capable of receiving the redirected 
queued events from the redirector and incorporating 



each of the redirected queued events in a packet con- 
forming to a network protocol which can be sent through 
the network interface and over the network to one or 
more of the shared computers. 

Typcially, one or more of the messages include any 
one of the following: an operating system message, an 
application message, a input device message, and a 
message produced by one or more of the shared com- 
puters; an input device message may be created by one 
or more of the following: keystrokes from a keyboard, 
mouse clicks and movements, pen input, or speech sig- 
nals from a speech recognition system. 

Typically one or more of the events is a browser re- 
quest, more particularly, one or more of the queued 
events are Common Client Interface (CCI) events cre- 
ated by the browser. In the preferred embodiment, the 
CCI event is converted into an operating system proto- 
col, preferably Dynamic Data Exchange (DDE). 

Examples of CCI events include any one or more 
of the following: a request for opening a page, a request 
to change a window size, a request to register a proto- 
col, a request to unregister a protocol, a request to get 
window information, a request to be notified when a new 
page is open, and a request to be notified when a win- 
dow size is changed. 

In one preferred embodiment, the input device is a 
pen capable of producing a signature and the document 
has one or more windows where the signature is placed. 

The invention further provides a method of operat- 
ing a computer system having a display, a network in- 
terface for communicating to a network, and a browser 
for sending requests for pages over the network and dis- 
playing the requested pages on the display, said method 
including the steps of: 

retrieving a message from a memory; 
duplicating the message if the message is neces- 
sary for a browser to create a page on the display; 
and 

sending the message over a network to a sharing 
computer so that a receiving browser on the sharing 
computer can use the message to create a received 
page on a received display that is identical to the 
page. 

The system and method described herein allow two 
or more users of the Internet to simultaneously collabo- 
rate (view, move on, and/or change) a HTML page, and 
allow one or more browsers used on the Internet to si- 
multaneously control one or more other browsers used 
on the Internet. In particular one or more standard 
browsers can be used on the Internet to simultaneously 
control one or more other standard browsers used on 
the Internet without modifying the browsers or computer 
operating systems. 

In a preferred embodiment, one or more client com- 
puter systems have a memory, one or more central 
processing units (CPU), an interface to a network, and 
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a browser. A network, e.g. the Internet, provides a com- 
munication link between the one or more first (e.g. 
source) clients and one or more second (e.g. receiving) 
client computer systems using one or more Web serv- 
ers. The second client(s) also has (have) a memory, a 
CPU(s), a network interface and a browser. In the first 
and second clients, the browser is capable of accessing 
one or more HTML pages from one or more of the Web 
servers by sending one or more browser requests to any 
one of the Web servers. 

The sharing clients are one or more first and one or 
more second client computer systems that are collabo- 
rating with one another through their respective web 
sharing manager. The web sharing manager of a receiv- 
ing sharing client receives the duplicated events (e.g. 
browser requests) and messages from the web sharing 
manager of a source sharing client and causes the 
browser of the receiving sharing client to execute the 
duplicate event/message so that the browsers of the 
source and receiving sharing client computer system(s) 
process the same events/messages. Because events/ 
messages, including control and information locations 
(addresses), are shared between the source and receiv- 
ing sharing client(s), the same web page is simultane- 
ously displayed and controlled on all of the sharing client 
(s). Examples of events that are shared between clients 
include the following browser requests: location of infor- 
mation on the WWW, gateway connections to additional 
networks (including telephone networks), etc. Examples 
of messages include: input/output controls like mouse 
controls, pen controls, and keyboard input; operating 
system messages, and application messages. 

In a particularly preferred embodiment, there is no 
need to change the browser or the operating system of 
the computer from currently available version, as long 
as the browser has a "registration function" and the op- 
erating system has a 'hooking function". The registra- 
tion function causes certain events, for example CCI 
events, to be routed to a redirector while the hooking 
function permits a message redirector access to a mes- 
sage queue of the operating system. The registration 
function and hooking function work with one or more re- 
directors in the sharing clients to route duplicate browser 
events and messages among the sharing clients so that 
the same web page appears on each of the sharing cli- 
ents. 

Preferred embodiments of the invention will now be 
described in detail by way of example only with refer- 
ence to the following drawings: 

Figure 1 is a block diagram of a preferred embodi- 
ment of the invention used in a client/server network 
architecture; 

Figure 1 A is a block diagram of a detail of the sys- 
tem in Figure 1 that also shows the flow of events 
(e.g., browser requests) and messages; 
Figure 2 shows a sample of a Web document (web 
page) that can be shared by the system of Figure 1 ; 
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Figure 3 shows a hierarchy of windows (parent- 
child relationship) for the Web sample document of 
Figure 2; 

Figure 4 shows an example of a shared Web doc- 
s ument and the use of mapping; 

Figure 5, comprising Figures 5A and 5B, are exam- 
ple block diagrams of a mapping table data struc- 
ture; 

Figure 6 is a block diagram of communication pack- 
10 et; 

Figure 7 is a flow chart showing the steps of regis- 
tering, processing, and unregistering an event (e.g. 
CCI event) during a web sharing collaboration; 
Figure 8 is a flow chart showing the steps creating 
is and sending a packet with an (CCI) event by a 
source machine; 

Figure 9 is a flow chart showing the steps of receiv- 
ing a packet with an (CCI) event at a receiving ma- 
chine; 

20 Figure 10 is a flow chart showing the steps of reg- 
istering a message queue hooking, processing an 
input message, and unregistering a message 
queue hooking during a web sharing collaboration; 
Figure 11 is a flow chart showing.the steps creating 

2S and sending a packet with an input message by a 
source machine; 

Figure 12 is a flow chart showing the steps of re- 
ceiving a packet with a input message at a receiving 
machine; 

30 Figure 1 3 is a diagram showing examples of various 
web page sharing collaborations between a cus- 
tomers) and an agent(s); and 
Figure 14 is flow chart of process steps performed 
by a message redirector process. 

35 

Figure 1 is a block diagram of one preferred embod- 
iment of the present system 100. The system 100 is a 
computer network 1 1 5 with one or more servers 1 1 0 and 
one or more client computers 150 (e.g., 150A and 

40 150B). In a preferred embodiment, the network uses a 
TCP/IP protocol 120 for communication among the var- 
ious clients 150 and servers 110. The protocol 120 is 
hardware that connects clients 150 to the network 115 
and usually also includes software resident on the client 

45 main memory 1 80. The protocol 1 20 hardware and soft- 
ware (also referred to as the network interface) are well 
known. One preferred embodiment of the network 115 
is the internet and the WWW. 

Each of the clients 150 (e.g. 150A and 150B) is a 

50 computer with a central processing unit (CPU 1 70), stor- 
age memory(ies) 1 75, main memory(ies) 1 80, and input/ 
output (I/O) interface(s) 185. The I/O interfaces 1 85 per- 
mit input devices 190, like a mouse, keyboard, pen over- 
lay, virtual reality inputs, speech recognition system to 

55 be processed by the CPU 170 and operating system 
195. Other I/O interfaces 185 operate graphical user in- 
terfaces (GUI) 135 on the client. Equivalent client com- 
puters 150 are well known. One preferred example of a 
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client computer is any IBM personal computer, e.g. an 
Aptiva (a trademark of the IBM Corporation). Speech 
recognition systems like the I BM VoiceType 3.0 dictation 
system are also well known. (VoiceType is also a trade- 
mark of the IBM Corporation). Examples of virtual reality 
inputs and systems are given in International Patent Ap- 
plication Number WO 95/08793 assigned to Virtual Uni- 
verse Corporation (U.S. Patent Application number 
08/125,950) with a priority date of September 22, 1993. 

Each of the clients 150 (e.g., 150A and 150B) par- 
ticipating in this web page sharing also have processes 
executed by the client. See Figure 1 A for more detail of 
Figure 1. Typically, these processes reside on the main 
memory 180 of the respective client (150A and 150B) 
and include a known Web Browser 130, a known Web 
Sharing User Interface 1 35, an optional known Annota- 
tion device (Annotator) 142, and an optional known Re- 
mote Pointer 144. A Redirector (in one preferred em- 
bodiment, a Common Client Interface Redirector) 145, 
a Message Redirector 155, and a Web Sharing Manager 
160 are also provided as processes running on each cli- 
ent 150. 

In the following discussion, one or more clients orig- 
inating an event (e.g. a request) and/or message in the 
web page sharing collaboration is called a source or 
sending sharing client (or machine) or source client/ma- 
chine and is designated 1 50 A. Reciprocally, one or more 
sharing clients receiving an event and/or message is 
called a receiving sharing client (or machine) or receiv- 
ing client/machine and is designated as 150B. Of 
course, these sharing clients can and do interchange 
roles. Components of the source 150A and receiving 
1 50B machines have their numeric designators append- 
ed with "A" or "B", respectively. 

For clarity in Figure 1 , some processes are omitted. 
However more detail is shown in Figure 1 A. All clients 
150 have the Web Browser 130, Web Sharing User In- 
terlace 135, a redirector (e.g. a Common Client Inter- 
face (CCI) redirector 145), message redirector 155, and 
web sharing manager 160. Clients 150 also typically 
have input/output (I/O) ports 185 and optional drivers 
like the annotation (annotator) 142 and remote pointer 
144 drivers. 

In a preferred embodiment, the web sharing man- 
ager 160 and redirectors (145, 155) are processes that 
are independent of the browser 130 and operating sys- 
tem 195. However, the redirector processes (145, 155) 
connect to the browser 130 through a registration func- 
tion 130F and to the operating system 195 through a 
hook 191 so that they can access event information from 
the browser and access and provide message and 
event information stored in a memory 165 used by the 
operating system 195. In a preferred embodiment, the 
memory 165 used by the operating system to store and 
access messages and request/event information (in a 
message form) is a message/event queue (or queue) 
165. The redirectors (145, 155) make sure that the re- 
quest/events and messages are routed to the correct 



place in both the source and receiving sharing clients 
so that the same web page appears on all sharing cli- 
ents. 

The structure of the queue 165 is well known and 
5 defined by the operating system. Typically, the queue 
entries 171 (messages and events/requests in "DDE" 
message form) in the queue 165 have the structure in- 
cluding: a message type 166, parameters 167 associ- 
ated with the message, a destination 168 which speci- 
10 fies the receiver of the message, and other information 
169. 

By loading the web sharing manager 160 and the 
redirectors (145, 155) into the memory 180 of the shar- 
ing client 150, any client with a standard browser 130 

is (having a registration function 1 30F) and a standard op- 
erating system 195 with a hook 191 to the message/ 
event queue 165 can be converted to a sharing client 
1 50 that can collaborate with other sharing client(s) 1 50 
without modification to the browser 130 or operating 

20 system 195. 

In a preferred embodiment, the computer system 
150 uses the redirector (specifically a CCI redirector) 
1 45 to send duplicate (CCI) events 1 32AOut, generated 
by the browser 1 30 of the source client .1 50A, to one or 

2S more receiving clients 150B. The (CCI) redirector 145 
of the receiving clients 150B causes received (CCI) 
events 1 32Aln to be processed appropriately and routed 
to the browser 1 30 in the receiving client 150B lor exe- 
cution. (Note that in this disclosure, event and CCI event 

30 and redirector 145 and CCI redirector 145 will be used 
interchangably without loss of generality.) 

The sharing client computer system 150 also uses 
the message redirector 1 55 to duplicate messages (like 
keyboard and mouse inputs 185) produced by the 

35 source client 150A and sends these duplicate messag- 
es 165AOut to the receiving client(s) 150B. The mes- 
sage redirector 155 is used by the receiving client 150B 
to mark or tag (see below) received messages 165Aln 
and works with the operating system 195 to process 

40 these received messages l65Aln. 

The Web Browser 130 can be any commercially 
available network browser that has a registration func- 
tion, e.g., Netscape Navigator 130. The Web Browser 
130 communicates to the network 115 and servers 110 

45 using well known internet protocols (e.g. http, ftp) on top 
of a TCP/IP protocol. 

The Web Sharing User Interface 135 provides the 
look and feel for users of this package to establish the 
connection, to invoke tools (for example, remote pointer 

so 144, annotation 142), to share or unshare the Web 
browser's document, and to show the status of other us- 
ers. Since the user interface component 1 35 used in this 
system 100 is a simple and known function that can be 
found on most desktop conferencing systems, it will not 

55 be described further. 

The annotation or annotator 142 provides handwrit- 
ing (or pen based) capability to write comments or high- 
light some areas of a web document and the remote 
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pointer 144 is used to point to or to move around the 
objects on a shared document. A pen input device 190, 
if it is available, may be used for annotation or pointing 
(alternatively, a mouse 1 90 can be used). This capability 
of annotation 142 and the remote pointer 144 is well 
known in the desktop video conferencing products (see 
for example, the IBM Person to Person product). 

Refer again to Figure 1 A, a block diagram of a detail 
of the system in Figure 1 , that shows the flow of infor- 
mation and controls (events and messages) among 
components in the system. 

A preferred embodiment includes two software 
components: the CCI redirector 145 and the message 
redirector 155. The CCI redirector 145 monitors and 
routes the CCI events 1 32A that the browser 1 30 sends 
and/or requests and the CCI events 132Aln that are re- 
ceived from the network 115. The message redirector 
155 captures and routes the input data messages from 
input devices (e.g., keyboard, mouse, pen messages) 
190 and other sources. In alternative embodiments one 
"redirector" could perform the functions of both the CCI 
redirector 145 and the message redirector 155. In other 
alternative embodiments, the redirecting could be per- 
formed by the browser and/or the web sharing manager 
that are designed specifically to include these functions. 

The preferred embodiment uses a "registration" 
feature 130F of known browsers 130. Many browsers 
call this registration feature a Common Client Interface 
(CCI) (132, 1 30F). The CCI 132 of some Web browsers 
130, for example the NetScape Navigator, provide fea- 
tures for external programs to control and extend the 
functionalities of the browser 130 through this cross- 
platlorm interface (CCI 132). The CCI 132 is specified 
as a set of interfaces which can be used to communicate 
either to or from Web browsers 1 30. Using this CC1 1 32, 
the user defines the CCI events 132A that the browser 
is to pass to an external process, here the CCI redirector 
145. Therefore, every time that the browser 1 30 gener- 
ates a "registered" CCI event, the browser not only 
sends the CCI event 1 32 A1 through the TCP/I P protocol 
120 to the network 115 but also sends a duplicate CCI 
event 132A to the operating system 195. In a preferred 
embodiment the operating system 195 applies a Dy- 
namic Data Exchange (DDE) protocol 131 to the dupli- 
cate CCI event 132A before the operating system 195 
stores the CCI event 1 32A, preferably in the queue 1 65. 
The DDE protocol makes the CCI event/request 132A 
appear as a DDE message in the queue 1 65. The detail 
specification of CCI 1 32 for the NetScape Navigator is 
described in http://home.netscape.com/newsref/std/ 
ddeaplhtml for the Netscape browser 130. 

The Netscape Navigator in a Windows platform us- 
es DDE 1 31 to implement CC1 1 32 (Windows is a trade- 
mark of Microsoft Corporation). DDE 131 is a known 
message based interprocess communication protocol 
defined in the Windows platform and used by the brows- 
er 130 and as described herein by the CCI 132. 

For example, when a user/client 150 opens a new 
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Web document by explicitly specifying a URL of the doc- 
ument or by clicking a hyperlink to a URL document, the 
browser 130 sends an event (request) 132A1 request- 
ing a page from the Web server 110 through the TCP/ 

5 IP interlace 120. Since the CCI redirector is pre-regis- 
tered (1 30F, 1 32) for monitoring CCI events (see Figure 
7 below), the browser 130 also sends a (duplicate) CCI 
event 132A called OpenURL to the operating system 
1 95 that applies the DDE protocol 1 31 to the event 1 32A 

io and places it one the queue as a DDE message. The 
CCI event 1 32A is eventually routed (see discussion 
and Figure 14 below) to the CCI redirector 145 which 
causes the CCI event 1 32A to be routed through the web 
sharing manager 160 (as a "packet" -see Figure 6 be- 

is low) and through the network interface 1 20 over the net- 
work 115 to the shared receiving clients 150B. 

As another example, when the window of the Web 
browser 130 is changed (e.g. resized or maximized by 
a user 150), a CCI event 132A called WindowChange 

20 is sent by the browser 1 30 to the CCI redirector. 

In DDE protocol terminology, OpenURL or Win- 
dowChange CCI events 132A are set in a DDE topic 
name and the URL of the document or the new size of 
the browser's window is set in a DDE item. In the entry 

25 171 of this DDE message, the message type 166 will be 
set to "DDE message", the parameter field 167 will con- 
tain CCI event 132A, and the destination field 168 will 
be the CCI redirector. 

The message redirector 155 routes all messages 

30 incoming 1 65 Aln f rom the network 1 1 5 to the que ue 1 65 
and monitors all queue entries (events/requests and 
messages) on the queue 165 that are processed by the 
operation system 195. The message redirector 155 
monitors the queue 165 by "hooking" the queue. The 

35 message redirector 155 processes certain queue en- 
tries, e.g. messages and events, in the queue 165 in 
which the message redirector 1 55 has an "interest". This 
is described in more detail below. 

The preferred embodiment uses a known feature 

40 called hooking 191 provided by the operating system 
195 to catch all queue entries 171 in the queue 165. If 
a hook is installed with the operating system 195, all re- 
trieved queue entries 171 from the queue 165 are 
passed to the hook 191. The hook 191 permits the mes- 

45 sage redirector 155 to check 156 the message type 166 
to determine whether the message redirector has an "in- 
terest", i.e. will process the queue entry 171 . If the mes- 
sage redirector 155 has no interest, control is passed 
back to the operating system 1 95 so that the queue entry 

so 171 can be further processed by the operating system 
191. However, if the message redirector 155 has an in- 
terest 156, the message redirector 155 processes the 
queue entry before the operating system is allowed to 
deliver the queue entry 171 to its destination, e.g. an 

55 application. After the message redirector 155 has com- 
pleted its processing, control is returned to the operating 
system 1 95 to further process the queue entry 171. The 
message redirector 155 has an interest in those mes- 
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sages (not including DDE messages handled by the CCl 
redirector) necessary to recreate the web page at the 
source sharing client 150A on the receiving sharing cli- 
ents) 150B. 

For example, the CCl event 132A is put into the 
queue 165 by the operating system 195 as a DDE type 
166 message. When the operating system 195 is re- 
quested to retrieve a queue entry (the DDE message/ 
CCl event 132A), the operating system 195 checks if 
there is any hook 191 before delivering this CCl event 
1 32A to the destination application. Since the message 
redirector 155 hooks 191 the queue, the operating sys- 
tem 195 passes control of the CCl event 132A to the 
message redirector 155. The message redirector 155 
checks the message type field 166 to determine 156 if 
the message redirector 1 55 needs to process the queue 
entry 171. Since, in this embodiment, the message re- 
director 155 ignores all CCl events (DDE message 
types 166), the processing of the CCl event 132A by 
message redirector ends and control passes back to the 
operating system 195. 

The operating system 1 95 then uses the destination 
field 168 of the DDE message to deliver 193 the DDE 
message. If the CCl event originated in the browser 1 30, 
the browser placed the CCl redirector 145 as the desti- 
nation in the destination field 168. However, if the CCl 
event 1 32Aln originatedf rom an external source sharing 
client and was received from the network, the CCl redi- 
rector 145 placed the browser 130 (associated with its 
client 150A) as the destination in the destination field 
1 68. In either case, these CCl events are made into DDE 
messages by the DDE 131 and placed on the queue 
165. 

As the entries 171 in the queue 165 are processed 
(see hook 191 below) the operating system determines 
how to route the CCl events 193. In the case of the CCl 
event that was received from a source sharing client 
150A, the destination field 168 indicates that the mes- 
sage will be directed 193 to the browser 130. However, 
the CCl events that are generated at the source sharing 
client 150A have a destination 168 of the CCl redirector 
145 and are directed 193 there 145. The CCl redirector 
requests the Web Sharing Manager 1 60 to send this CCl 
event 132AOut across the network 115 to the receiving 
sharing client 150B. The receiving sharing client 150B 
will use this CCl event (now a 132Aln) to duplicate the 
CCl event (e.g. request) on the receiving sharing client 
150B so that the web pages on all of the shared clients 
are kept the same. 

A "hook* 191 is a well known operating system 1 95 
defined function that allows external processes to inter- 
cept queue entries 171 in the memory, e.g. the queue 
165, of the operating system 195. Once an external 
process invokes the hook, the operating system 195 
passes requested information, e.g. one of the queue en- 
tries 171, to the external process. 

Once the external process, e.g. the message redi- 
rector 155, completes its function, the external process 



passes control back to the operating system 195 by 
some indication like a "return' in the function call. For 
example, in the Windows 95 operating system the 
"hook* is defined in the "Software Development Kit" 

5 (SDK) referenced in Win32 Programmer's References. 
For the OS2 operating system (OS/2 is a trademark of 
IBM Corporation), it is defined in Presentation Manager 
Programming References. 

Queue entries 171 can originate from several plac- 

10 es. As described above, duplicate CCl events 132A 
originating from the CCl 132 in the browser 130 are 
placed in the queue 165 after the DDE protocol is ap- 
plied. Also, received CCl events 132Aln are identified 
161 by the web sharing manager 160 and pass through 

J5 the redirector 145 and DDE 131 to the queue 165. The 
DDE assigns each of the CCl events (1 32A and 1 32Aln) 
with a message type 166 "DDE message" and a desti- 
nation 168 as described above. 

In addition to events, queue entries 171 include 

20 messages. Messages can be generated by the operat- 
ing system 195 (internal messages) or by sources ex- 
ternal to the operating system 1 95 (external messages). 
External messages include messages from the input de- 
vices 190 and the I/O port 185, messages generated by 

2S inter-process communications, and messages received 
from a sharing client 1 50 connected through the network 
115. 

The operating system 195 generates internal mes- 
sages that include: "scrolling", "move a window", "resize 

30 a window", "minimize a window*, and 'maximize a win- 
dow". These messages are defined in the SDK for the 
operating system 195. The operating system 195 gives 
these internal messages a "window message" message 
type 1 66 and the window handle of the appropriate win- 

35 dow as a destination 1 68. 

Messages from input devices 190 include: key- 
board messages like "key up", "key down", and "key 
code" (e.g. an ASCII value); mouse messages like 
"mouse up", "mouse down", "mouse move*, and "mouse 

40 double click"; pen messages like "pen up", "pen down', 
and "pen move"; and annotator messages line "annota- 
tor up", "annotator down", and "annotator move." For 
each of these messages, the operating system 195 as- 
signs a queue entry 171 message type 166. For exam- 

45 pie, if the left mouse button moves up, the message type 
166 will be "mouse left button up." Further the destina- 
tion field 168 will contain the window handle of the win- 
dow where cursor is located. The parameter field 167 
will contain the (X, Y) of the mouse cursor and the other 

so field 169 might contain other information like a time 
stamp. Populating these queue entry data structures 
171 in this way is well known. 

Messages are commonly used as the inter-process 
communication between applications, especially in a 

55 message based window system (e.g. Windows 3.1 or 
OS/2). When an application requests an operating sys- 
tem 1 95 to send a message to another application, the 
operating system 195 puts the message into a queue 
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1 65 and then delivers the message when the destination 
application requests the operating system 195 to re- 
trieve a message from the queue 165. This message 
event/queue 165 is also used to put and deliver other 
known messages to the applications (e.g. when the win- 
dow of the application needs to be repainted). 

Similar to the inter-process communication be- 
tween applications, communications between the input 
devices 190 and the applications are also through the 
queue 165. All input data, defined above by example, 
from input devices 190 (e.g. keyboard, mouse, pen) are 
transformed into well defined messages by the window 
operating system 195 and are put into queue 165. To 
read its input data, each application will request the win- 
dow system to retrieve the messages from the message 
event queue 165 as a queue entry 171 . 

In one preferred embodiment, messages are re- 
ceived by one or more receiving sharing clients 150B 
from the network 115. These messages are passed 
through the web sharing manager 160 which deter- 
mines 161 whether the received signal is a message or 
an (CCI) event (e.g. request). If the received signal is a 
message 165Aln, the message is passed through the 
.message redirector 155 and then to the operating sys- 
tem where it is placed on the queue just as any other 
external message. However, in this case, the message 
165Aln is tagged to indicate that it came from the mes- 
sage redirector 155, i.e., the network 115. In a preferred 
embodiment, the message redirector 155 tags the mes- 
sage by adding a fixed number (e.g. an offset) to the 
message type field 1 66 which produces a message type 

166 that is understood by the message redirector to 
identify any message from a remote source sharing cli- 
ent 1 50A. Note that these messages 1 65Aln can include 
any of those messages that are generated by a source 
sharing client 150A and received over the network 115 
either as application messages, input device messages, 
or as internal operating system messages. 

Since the message redirector 155 has hooked 191 
the queue 165, the message redirector 155 examines 
each of the queue entries 171 in the queue 165. How- 
ever, the message redirector 155 only has an interest, 
i.e. only processes, certain of these queue entries 171 . 
In general, the message redirector 155 needs to proc- 
esses only those queue entries 170 that are required to 
create the same page on any of the sharing clients 150. 

Examples of queue entries 171 that are processed 
by the message redirector 155 include queue entries 
with message types 166: "key code 1 for the key board, 
'mouse (left or right) button (click or double click)", 
"mouse move", "scrolling", and "window (get/lost input 
focus)" messages. These messages are tagged by the 
message redirector. 

Examples of queue entries 1 7 1 that typically are not 
processed by the message redirector 1 55 include queue 
entries 171 with message types 166: "key up (down)", 
"mouse (left or right) button (up or down)", "window 
(move or resize)", "window (active or inactive)", "window 



(create or destroy)", "menu selection", and any DDE 
message. This is because these queue entries do not 
effect the appearance of the web pages displayed by 
the browser. 

s As the operating system 195 processes the queue 
entries 171, "non DDE" messages are hooked 191 to 
the message redirector 155. Upon determining 154 that 
the message redirector 155 has an interest in the mes- 
sage, control is passed to the message redirector 155 

io and the queue entry 171 is processed by the message 
redirector 155. If the message redirector recognizes the 
message type 1 66 of the message as that indicating the 
message came from a source sharing client 150A, the 
message redirector changes the message type 166 

is back by removing the tag, e.g., by subtracting the offset 
from the message type 166. The message redirector 
155 also changes the destination 168 of the message 
to that of the browser 130, replaces the message in the 
queue, and returns control to the operating system 1 95. 

20 These messages, even though they originated at a re- 
mote source sharing client 150A are processed by the 
browser 1 30 to maintain the web pages of the sharing 
clients 150A.B in the same state. 

However, if the queue entry 171 is a message that 

25 originated at the source sharing client 150A, the mes- 
sage redirector duplicates the message l65AOut and 
sends it through the web sharing manager 1 60 and the 
network interface 120 over the network 115 to the re- 
ceiving sharing clients 150B. 

so Control is then returned to the operating system 1 95 
which processes the message within the source sharing 
client 150A. 

The Web Sharing Manager 160 provides the func- 
tionality to send both the CCI events 132AOut and mes- 

35 sages 165AOut through the TCP/IP network interface 
120 to the receiving sharing client(s) 150B. Also, the 
Web Sharing Manager 1 60 creates a proper header for 
receiving packets, through the network 115, from source 
sharing clients 150A. This is described in more detail 

40 with reference to Figure 6 below. 

The CCI events 1 32Aln and messages 1 65Aln sent 
to the sharing receiving client 1 50B inform the web shar- 
ing manager(s) 160B of the sharing receiving client 
150B what the source sharing client 150A is doing. The 

45 web sharing manager 160B receives the sent CCI 
events 132Aln and messages 165Aln, strips the Web 
Sharing Manager header 620 of Figure 6, and deter- 
mines 161 whether they are CCI events or messages in 
order to route them to the CCI redirector 1 45 or message 

so redirector 1 55, respectively. The operating system 1 95, 
message redirector 155, and CCI redirector 145 then 
operate together, as defined above, to permit the real 
time sharing or collaboration, i.e. all sharing clients 
150A.B view and control their respective web page the 

55 same way. Also the same information, e.g. data, mes- 
sages, etc. is viewed on the GUI displays (web pages) 
of all the sharing clients. 

By using this technique, all sharing clients 150A.B 
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collaborate to share the same web page, i.e. both or all 
users will see the same Web document displayed by 
their respective Web browser 130. It a sending user 
150A, tor example, inputs some keystrokes trom the 
keyboard, creating message events 165A, the same 5 
keystrokes will be displayed on the receiving user 150B 
screen in the same way as it these keystrokes are input 
by the receiving user 150B. This sharing tunction of in- 
put is realized by the message redirector 1 55 which cap- 
tures the input messages (e.g., keyboard, mouse mes- 10 
sages) in the message queue 165 in the source client 
150A and redirects the same messages as message 
events 165A to be replayed in receiving sharing clients 
150B. 

All the processes performed on the clients 150 are is 
transparent to the Web server(s) 110. The web server 
only handles communication packets (see Figure 6 be- 
low) with standard communication headers 610 that 
contain the sharing requests and information. All other 
functions of the server are the same as any typical 20 
WWW function. In a typical environment, the Web doc- 
uments) displayed by the Web browser 130 is (are) re- 
trieved from the Web server(s) 110. With the hyperlink 
capability, this Web document may be linked to other 
Web documents in the same Web server 1 1 0 or in other 25 
Web servers 110 in the network 115. The Web server 
110 is used as the repository of Web documents 
browsed by the Web browser 130. 

Therefore, the CC1 132 with the CCI redirector 145 
(and the message redirector 155) monitor CCI events 30 
1 32 A (messages 1 65A) independent of the use of these 
CCI events 1 32 A (messages 1 65 A) by th e system 1 50A, 
so that they can be transparently passed over the net- 
work 115 to other sharing receiving clients 150B collab- 
orating with the source sharing system(s) 150 A. 35 

Figure 2 shows an example of a Web document 
200, displayed on the GUM 35 of the Web browser 1 30, 
which includes, for instance, a parent window 200 and 
one or more child windows (201-205). Here the child 
windows include: one text entry 201 object (e.g. for en- 40 
tering an account number), one multiple-line entry ob- 
ject 202 (e.g., for comment), two push-button objects (e. 
g. for submitting 204 and clearing 205 the document), 
and a nove I white area 203 (e.g. for a pen based or point- 
er based signature.) The Web document 200 is shown *s 
in the browser's window and other objects are created 
as the child windows (201-205) of this window. By 
known techniques, the browser window is created when 
the browser starts and it persists until the browser is 
ended. The child windows (201 -205) are created at the so 
time the browser displays the Web document and they 
will be destroyed when the browser displays a new doc- 
ument, i.e. the child windows (201 -205) in the document 
200 are dynamically created and destroyed. Also in Fig- 
ure 2, the pen 250 and the pointer 260 represent the 55 
functionality of the Annotation 142 and the Remote 
Pointer 1 44, respectively. When the window of Web doc- 
ument 200 and its child windows (201-205) are created 
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or destroyed, 'window (create or destroy)" messages 
are generated by the operating system 195. However, 
these messages need not be processed or duplicated 
by the message redirector 1 55 since the same messag- 
es will be produced in other sharing receiving clients 
150B by the operating system 195 of those 150B client 
(s). This occurs in two instances: 1 ) moving on to anoth- 
er page and 2) explicitly closing the page. When moving 
on, the sharing client must create a new page and there- 
fore closes the current page. When explicitly closing a 
page, the CCI event closing the page is shared with the 
client 150B and will cause the client's operating system 
195B to close the current page. 

Figure 3 shows the hierarchy of windows 300 (par- 
ent-child relationship) for the Web sample document of 
Figure 2 embodied in a data structure. In a window sys- 
tem (e.g., Windows 3.1 or OS/2), each window, includ- 
ing the browser window, is identified by a number called 
a window handle which is unique and is only valid in the 
window system that creates it. This window handle, or 
■handle* is used to send/receive messages to/from oth- 
er windows. The handle for the browser's window 310 
is, for example, 2000. The browser window handle 2000 
is static and is not changed until the browser is finished 
running. However, the handles 2021 , 2022, 2023, 2024 
and 2025 of the respective child windows 321 , 322, 323, 
324 and 325 will be dynamically created. These child 
handles (2021-2025) are valid only when the child win- 
dows are valid and will not be reused after these child 
windows are destroyed, e.g. when the browser jumps to 
a new document. These window handles (2021-2025) 
are used by this Web sharing system 100 to display the 
same document and to support the same input from var- 
ious input devices (e.g. keyboard, mouse, pen) over two 
or more clients 150. 

Figure 4 shows an example of sharing a Web doc- 
ument 200, such as http://www.bank.com/homepage. 
htm, between a customer (here, for example, the source 
1 50A) and a bank agent (here, for example, the receiver 
150B). 

There a two types of information to be shared be- 
tween the customer and the bank agent: the view of the 
Web document 200 and the input data (e.g. keyboard 
input for the account number) 233. The sharing of the 
view of Web document 200 is realized by the CCI redi- 
rector 1 45 as a CCI event 1 32A, whereas the sharing of 
input data 233 is realized by the message redirector 1 55 
as a message event 165 A. The detailed mechanisms 
used by the CCI redirector 145 and the message redi- 
rector 155 to support sharing of Web documents will be 
described below. 

More detail is now given about the mechanism used 
by the Web sharing system 100 to share the same Web 
document between source 150A and receiving 150B 
machines. 

At the source 150A machine, when the customer 
opens a new URL, the Web document 200(A) is shown 
in the browser's 1 30A window having, for example, 2000 
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as the window handle. After the Web page is displayed, 
the browser 130A sends a CCI OpenURL event using 
the DDE protocol to CCI Redirector 145A as notification 
that the Web page is successfully opened and dis- 
played. The CCI Redirector 145A redirects this Open- 5 
URL event 1 32A to the Web sharing manager 1 60A to 
process this event 132A. After receiving this OpenURL 
event, the Web sharing manager 160 enumerates the 
hierarchy of windows (as shown in Figure 3) of the open 
document, assigns an ordering number to each window, 10 
and builds a table, for example, as shown in Figure 5A 
for the customer machine 160A. For example, in Figure 
5A, the document 200A of Figure 4 shown in the cus- 
tomer machine 150A has a window handle of 2000 and 
an ordering number 0. The child window 201 A for doc- is 
ument 200A for the account number 233A has a window 
handle 2021 (41 OA) and an ordering number 1 . The win- 
dow handles are. created by the window system and are 
destroyed each time the associated windows are 
closed. Therefore, the window handles cannot be used 20 
to identify the child windows in the open Web page since 
the same Web page may be reloaded (closed and reo- 
pened) by the browser. I nstead of using the window han- 
dles, the Web sharing manager 160A uses the ordering 
numbers to identify the Web document's window and its 2s 
child windows. For example, the ordering number 0 is 
used to identify the Web document's window 200A, the 
ordering number 1 is for the the child window 201 A for 
account number 233A. 

At the bank agent (receiving) machine 150B, the 30 
Web sharing manager 1 60B receives the OpenURL CCI 
event 132 A (from the Web sharing manager 160A) 
through the network 115 and passes this OpenURL CCI 
event 132A through the CCI redirector 145Btothe Web 
browser 130B for opening a new URL. After receiving 35 
this request, the Web browser 1 30B opens and displays 
the Web document in its window having, let say, 5000 
window handle. Similar to the creation of Figure 5A in 
the customer machine 150A, the Web sharing manager 
160B enumerates the hierarchy of windows (as shown 40 
in Figure 3) of the open document 200B, assigns an or- 
dering number to each window, and builds a table, for 
example, as shown in Figure 5B for the customer ma- 
chine 150B. 

The mapping table data structure 500 is used by the 
web sharing manager 1 60 to map the window of the Web 
browser and its child windows on one client 1 50A to their 
corresponding windows on receiving clients 150B. 

This mapping table 500 has records, typically 510, 
each having three or more fields. The first field 520 con- so 
tains an ordering number of a window, a second field 
530 contains the window handle of the respective win- 
dow, and a third field 540 contains a type of the respec- 
tive child window (321-325) (e.g. text, bit map, etc.) in 
the document 200. For instance, this table 500 is used 55 
to map a child window 203A in one machine (e.g. 1 50A) 
to the corresponding child window 203B in another ma- 
chine 150B. 



Since the browsing of Web document 200 and the 
processing ol input data from the input device 190 are . 
based on the information of the windows, the mapping 
table, as shown in Figure 5, will allow the Web sharing 
system 100 to display the same Web document in the 
correct window of the Web browser 130 and to redirect 
the same input data to the right Web document. 

For example, by using the table 500, all keyboard 
messages 165A sent to the window handle 2021 in the 
customer machine 150A are mapped to the messages 
165B sent to window number 3 (in the ordering number 
field 520 of table 500) of the second machine 1 SOB. This 
window numbe r 3 will be known to have the window han- 
dle 5010 in the second machine 150B, e.g. the bank 
agent machine. Using this mapping mechanism 500, the 
keyboard input 190 to the text entry window 203A will 
be sent to the corresponding text entry window 203B, 
and the customer and the agent will see the same ac- 
count number displayed on their screen. Other window 
types are mapped in the same way. 

This capability enables all clients 150 to see or 
share the same Web document shown on their screen 
by the Web browser 130 and the same input data from 
input devices 190 into the shared Web document. When 
a user clicks on the hyperlink to browse a new Web doc- 
ument, other users will automatically follow the hyperlink 
to the same Web document. 

In addition to the sharing of Web document and in- 
put data, for example to imitate a face-to-face meeting, 
one user may use the remote pointer 144 to point to or 
to move around the objects in the shared document and 
other users engaged in the Web collaboration session 
will see the cursor of the remote pointer 144 displayed 
at and moved around the objects in discussion (since 
the movement of the remote pointer 144 will generate 
the mouse input data which are shared as described 
above). With the annotation 142, a user may use the 
pen input device, if it is available, or the mouse to write 
some comments or to highlight some areas on the 
shared document. The annotated comments or the 
highlights will simultaneous appear on other clients 
(since the annotation 142 will generate the pen/mouse 
input data which are shared as described above). This 
sharing of Web document and input devices will allow 
users to have a conference or meeting over the network. 
Thus with the aid of the annotation 142 and remote 
pointer 144, the conference or meeting created by the 
Web sharing system 100 has the same atmosphere as 
a face-to-face meeting. 

Figure 6 is a block diagram of communication pack- 
et 600 with a (e.g. TCP/IP) communication protocol 
used by the web sharing manager 160 to exchange re- 
quests and information between the client machines 
150. The packet 600 has a communication header 610, 
two or more Web Sharing Manager headers 620, and a 
data section 630 with one or more fields. The first header 
610, the communication header, is defined by TCP/IP 
protocols. This header 61 0 is well known. Since the Web 
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Sharing Manager provides common functions to send 
and receive data tor other components (CCI redirector, 
message redirector, etc.), it uses a special web sharing 
manager header 620 to identify the receiver (e.g., an- 
notation, remote pointer 144, CCI redirector 145, mes- 
sage redirector 155, web sharing manager 160) of the 
packet 600. This receiver information is contained in a 
receiver ID field 622 of the header 620. The web sharing 
manager header 620 further comprises a packet length 
624 field that contains the size (length) of the packet, i. 
e. the portion comprising the web sharing manager 
header 620 and the web sharing manager data 630. 
Other information can be included in the web sharing 
manager header 620. 

The Web sharing data 630 section of the packet 600 
is the data to be sent or received over the network 115 
to the "receiver' named in the Receiver ID field 622. The 
web sharing manager strips the web sharing manager 
header 620 before this packet data 630 is passed to re- 
ceiver. For example, the packet data 630 for CCI redi- 
rector 145 will include the type 632 of CCI event (e.g., 
Open URL event) and the parameter 634 of the CCI 
event (e.g. http://wwwjbm.cofTVhome.htm URL). Exam- 
ples of packet data 630 for the receiver's message re- 
director 155, remote pointer 144, annotation (e.g. pen 
based input) 144, will include the message types 632: 
keystroke from the keyboard 190, mouse 190, and pen 
stroke 190, respectively. The parameters 634 would be 
keycode, mouse position, and pen position, respective- 
ly. 

When the Web document 200 displayed by the Web 
browser 130 is shared, the view of the Web document 
200 in the Web browser's window as well as the input 
data (e.g. keyboard/mouse/pen input data) are shared 
between the source and receiving machines 150. The 
sharing of the view of a Web document is realized by 
the CCI redirector 145 by communicating CCI events 
132A whereas the sharing of input data is realized by 
the Message redirector 155 by communicating mes- 
sage events 165A. 

The CCI redirector 145 uses the CCI events (e.g. 
OpenURL, WindowChange) provided in the Web 
Browser 1 30 to implement sharing of the view of the web 
document 200 as described below. When user 150A 
opens a new HTML document or browses the docu- 
ments through a hyperlink, the Web browser 130A at 
the source machine (e.g. 1 50A) notifies the CCI redirec- 
tor 145A at the source machine 150A of CCI events 
1 32 A to be sent by the source machine 1 50A. Also, the 
CCI redirector 145B at the receiving machine 150B will 
pass the CCI events 132A at the receiving machine 
150B to its respective Web browser 130B for execution 
in the same way as if these CCI events 1 32A were gen- 
erated (as CCI events 1 32B) from the operations of user 
150B. An example of a received CCI event is a request 
to display a Web document 200 that the sending user 
150A opens. 

Figure 7 is a flowchart of a process 700, executing 



on both the sending 150 A and receiving 150B ma- 
chines, showing the steps of initialization, processing a 
CCI event 1 32, and a termination done by CCI redirector 
145 during the Web collaboration session. At the begin- 
5 ning of the Web collaboration, the CCI redirector 145 
registers with the Web browser 130 all the CCI events 
1 32 for which the CCI redirector 1 45 has an interest. By 
this registration relationship, step 710, the Web browser 
130 will notify the CCI redirector 145 by sending regis- 
10 tered CCI events 132 using the DDE protocol 131. Ex- 
amples of CCI events for which the CCI redirector 145 
registers include: RegisterProtocol, RegisterWin- 
dowChange, etc. The redirector 145 is interested in any 
CCI event 132A that is needed to create a document 
is view on the receiving machine 150B. 

For example, when a user 150A opens a new URL 
document, a CCI event 132 called Open URL, which is 
registered with the browser 1 30A in step 710 by CCI re- 
director 145A, is generated by the Web browser 130A 
20 and is sent to the CCI redirector 145A using the DDE 
protocol. By receiving this OpenURL CCI event, the CCI 
redirector 145 A knows that a new Web document 200 
is displayed by the Web browser 130A. By sending the 
name of the open Web document from the CCI redirec- 
ts tor 145A (a sender of CCI event) to the corresponding 
CCI redirector 145B (a receiver of CCI event) through 
the respective Web sharing managers 160, the same 
Web document 200 can be displayed on the receiving 
machine 150B by sending an OpenURL event from the 
30 CCI redirector 1 45B to the Web browser 1 30B using the 
DDE protocol 1 31 B. 

In step 720, CCI event 1 32A(B) is processed by CCI 
redirector 145B(A) as a sender (or a receiver) ot CCI 
event 1 32A(B). The machine 1 50A is a sender when the 
35 browser 1 30A sends a CCI event 1 32A to the CCI redi- 
rector 145A and the machine 150A is a receiver when 
when the web sharing manager 160A passes the com- 
munication packet 600 to the CCI redirector 145A. This 
step 720 is shown in more detail for a CCI sender 145A 
40 in Figure 8 and for a CCI receiver 145B in Figure 9. 
When the Web collaboration is terminated, the CCI re- 
director 145, in step 730, will unregister all registered 
CCI events 132 from the Web browser 130. 

Figure B is a flowchart of the steps 720 implemented 
45 on the source or sending client 150A that is notified of 
a CCI event from the Web browser 130. The CCI redi- 
rector 145 A first determines 810 that the machine 150 
is the source/sender 150A of a request from its web 
browser 1 30A. When the source web browser 1 30A no- 
se tifies the CCI redirector 145A of a CCI event 132A, step 
810, the CCI redirector 145A stores and updates 820 
the information (see Figure 5A) related to this CCI event 
132A for later use. The source CCI redirector 145A en- 
ters the type 632 and parameter 634 of the CCI event 
55 1 32 A into the network web sharing data packet 830. The 
CCI redirector 145A sends 845 the data packet 630 to 
its source Web Sharing Manager 1 60A. The source Web 
Sharing Manager 1 60A then creates 850 the entire com- 
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munications packet 600 by entering the receiver ID 622 
and packet length 624 in the Web Sharing Manager 
header 620 and providing any other communication 
header 610 information required. Note that the Web 
Sharing Manager 160 can send packets 600 to more $ 
than one client to create a multiple user session by pro- 
viding a receiver ID 622 and any communication header 
(TCP/IP) 610 inlormation required tor each respective 
client receiver 150B. The packet is then sent through 
the interface 120 by the Web Sharing Manager 160A 10 
using known techniques, e.g. TCP/IP. Step 840 termi- 
nates the CCI process 720 for the source machine 1 50A 
for any given CCI event 132A. 

Figure 9 is a flowchart of the steps 720 implemented 
on the receiving client 150B that receives a CCI event is 
132A from the Web Sharing Manager 160B. The Web 
Sharing Manager 160B disassembles the Communica- 
tion Packet 600. The CCI Redirector 145B first deter- 
mines that the machine 150 is the receiver 150B of a 
Web sharing data packet from the Receiver ID 622 that 20 
was disassembled by the Web Sharing Manager 160B. 
(Note that the receiver ID 622 can be the CCI redirector 
145B or the Message redirector 155B.) After determin- 
ing the type 632 and parameter 634 of the received CCI 
event 132A, the CCI redirector 145B converts 910 the 2s 
CCI parameters to the local ones, using the DDE proto- 
col 1 31 B. This is done by creating and providing the in- 
formation in table 550. (Note that the DDE protocol of 
the sender 131 A usually is the same as that of the re- 
ceiver 1 31 B. However, once the CCI event 1 32A is rec- 30 
reated at the receiver, it can then be converted by the 
CCI redirector 1 45B into a new format, e.g. Netscape to 
Mosaic.) 

As an example, in step 910, when machine 150B 
receives an OpenURL CCI event 1 32A, the CCI redirec- 35 
tor 1 45B passes the OpenURL CCI event to the browser 
130B (the request to execute the event in step 920) 
which will access the document to be opened from the 
server specified in the parameter 634. Then, as the 
browser 130B builds the document view, the CCI redi- *o 
rector 145B determines how many child windows there 
are and completes the information require in table 550. 
(Note that when the browser 130B initiated, the parent 
window was already created in table 550.) 

In step 930, the browser 130B executes the CCI *s 
event requested by the CCI redirector 145B. The local 
Web browser 130B has the same state, i.e. executes 
the same CCI Event 1 32A, as the remote Web browser 
130A, but uses the mapping of the local system 150B 
to create the identical document view in both places, so 
The result of the execution 930 of CCI event 132A is 
returned from the Web browser 130B to the CCI redi- 
rector 145B and may be stored and updated 940, if ap- 
propriate, by the CCI redirector 145B for later use in the 
table 550. Step 950 returns control to step 720 which ss 
continues to call process 800 until it terminates in step 
730. 

Messages and/or data are handled as Message 



Events 165A in a similar fashion as controls, i.e., CCI 
events 1 32. 

Figure 1 0 is a flowchart of a process 1 000, executed 
by both the sending 150 A and receiving 1 50B machines, 
showing the steps of initialization, processing input mes- 
sages, and termination done by Message redirector 1 55 
(sender or receiver) during the Web collaboration ses- 
sion. 

In a message-driven window system (for example, 
Windows 3.1 or OS/2), an application obtains data (pa- 
rameter 634) from input devices 1 90 (mouse, keyboard, 
pen, etc.) in the form of messages (mouse message, 
keyboard message, pen message, etc.) that the oper- 
ating system 195 sends to the application through its 
message queue 165. 

The Message redirector 155 is used to implement 
the sharing of data from input devices 1 90 among clients 
150. When a user 150 A inputs some data into the Web 
document, these input data are transformed by the op- 
erating system 1 95 into messages which are kept in the 
message queue 165A. The Message redirector 1 55A (a 
source or sender) captures or hooks 1 91 these input da- 
ta by intercepting the messages sent to the Web brows- 
er's objects (e.g., button object, text entry object, list box 
object) through the message queue 165. 

To have the same input to the Web document at oth- 
er clients 150B, the Message redirector 155A (a source 
or sender) sends the intercepted messages to its corre- 
sponding Message redirector 155B (a receiver) through 
the Web Sharing Manager 160B. Then, the receiver 
Message redirector 155B puts these messages into the 
message queue 165, on system 150B, in the same way 
as if these messages are generated by the operating 
system 1 95B for the local input devices 1 90B. 

For example, if the user 150A types his/her name 
into the text entry object for name input in a Web docu- 
ment, the message redirector 155A intercepts this key- 
board message and sends it to the corresponding mes- 
sage redirector 155B at other clients 150B. At each re- 
mote client 150B, the sent keyboard messages are put 
into the message queue 165, on machine 150B, and are 
retrieved by the text entry object for name input in the 
similar way as if these key strokes are locally input by 
the user 150B. As the result, all users will see the same 
name in their Web document. 

As another example, when machine 150B receives 
a message event 165A, the message redirector 155B 
maps the window ordering number 520A.B to the win- 
dow handle 530B so that the parameter 634 is placed 
in the message event queue 165B associated with the 
mapped window handle 530B. 

Therefore, at the beginning of the Web collabora- 
tion, the Message redirector 155 uses a known feature 
provided by the operating system 195 to hook (1010, 
1 91 ) the message queue 1 65. 

In step 1020, the input message is processed by 
message redirector 1 55 as a sender (when the operat- 
ing system 195 recognizes that the browser retrieved a 
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Message Event 1 65A from the message queue) or a re- 
ceiver (when the Web Sharing Manager 160A passes 
the Communication Packet 600 to the message redirec- 
tor 155) of input message. This step 1020 is elaborated 
for a message sender in Figure 11 and for a message 
receiver in Figure 1 2. When the Web collaboration is ter- 
minated, the message redirector 1 55, in step 1 030, uses 
a known feature of the operating system to unregister 
message queue hooking. 

In step 1030, the message redirector 155 termi- 
nates the processing by unregistering the hooking of the 
message event queue 165, i.e., if the browser 130 re- 
ceives a message from the queue 165 the message re- 
director 155 will not be called and step 1020 will not ex- 
ecute. 

Figure 11 is a flowchart of the steps 1020 imple- 
mented on the source or sending client 150A that inter- 
cepts the input message from the message queue 165, 
at a sending machine 150A The message redirector 
1 55 A first determines 1110 that the machine 1 50 is the 
source/sender 150A of an input message intercepted 
from the message queue 165A. Based on the type 166 
of the message, each message is checked to deter- 
mined whether or not it is necessary to send the inter- 
cepted message to others clients 1 50B (step 1 1 20). This 
step 1120 for processing each message is elaborated 
in Figure 1 4. If the message is needed to be sent to other 
clients 150B, the source message redirector 155A en- 
ters 1130 the type 632 and parameter 634 of the input 
message into the network web sharing data packet 630. 
(In general the type 632 is the message type 166 and 
the parameter 634 includes the fields 167, 168, and 169 
in the queue entry 171.) The message redirector 155A 
sends 1 1 35 the data packet 630 to its source Web Shar- 
ing Manager 160A. The source Web Sharing Manager 
160A then creates 1140 the entire communications 
packet 600 by entering the receiver ID 622 and packet 
length 624 in the Web Sharing Manager header 620 and 
providing any other communication header 610 informa- 
tion required. The packet is then sent through the inter- 
face 120 by the Web Sharing Manager 160A using 
known techniques, e.g. TCP/IP. Step 1150 terminates 
the message process 1020 for the source machine 
150 A for any given input message from the message 
queue 165 and returns control to step 1020. 

Figure 14 is a flowchart of the step 1120 performed 
by the message redirector 155. The operating system 
1 95 retrieves an entry 1 7 1 from the message queue 1 65 
(step 1 41 0) and it checks if the hook 1 91 is enabled (step 
1420). If the hook is disabled, the entry will be delivered 
to the destination 193. Since the message redirector 
1 55 has hooked 1 91 the queue 1 65, the message direc- 
tor will receive all entries 1 7 1 and it examines if the mes- 
sage type is of interest as described above (for example, 
key code, mouse button click or double click, mouse 
move, scrolling message, tagged messages). If the 
message type 166 is a tagged message (step 1440) in- 
dicating that the message came from a source client 



150A, the message redirector changes the message 
type 166 back by removing the tag (step 1450) and this 
entry 171 is passed to the destination 193. The message 
redirector 155 only duplicates the messages destined 
5 to the Web browser by examining the destination field 

168 (step 1460). If the destination field 168 is the Web 
browser window or its child windows, the processing is 
continued 1470 to step 1130 of Figure 11 . 

Figure 1 2 is a flowchart of the step 1 020 implement- 
10 ed on the client 150B that receives an input message 
from the Web Sharing Manager 160B. The message re- 
director 155B first determines that the machine 150 is 
the receiver 150B of a Web sharing data packet from 
the Web Sharing Manager 160B. The receiver message 
is redirector 1 55B then retrieves the type 632 of the mes- 
sage and its parameters 634 from the data packet 630. 
(In general, the type 632 will be the message type 166 
and the parameters 634 include the fields 167, 168, and 

169 of the queue entry 171 .) Since some parameters of 
20 the received message are only valid for the operating 

system where the message is intercepted, these param- 
eters are converted to the local parameters of each cli- 
ent 150B by the message redirector 155B (step 1210). 
The massage redirector 155B puts the received mes- 

25 sage together with its converted parameters (step 1 220) 
into the message queue 165, at the receiving machine 
150B. The Web browser 130B retrieves 1225 the mes- 
sage from the message queue 165B and processes 
1230 it in the same way as if this input message is from 

so the local input devices 1 90B. The sender Web browser 
1 30A and the receiver Web browser 1 30B then get the 
same input message, i.e. source user 150A and receiver 
user 150B share the same input data. Step 1240 termi- 
nates the message process 1020 for the receiver ma- 
ss chine 1 50B for any given data packet 630 from the Web 
Sharing Manager 1 60B and returns control to step 1 020. 

Figure 13 is a drawing showing some preferred us- 
es of the present system 100. In particular, an imple- 
mentation 1300 of an interactive customer and agent 

40 collaboration, e.g. in a Home Banking system, using the 
web page sharing system 100 is described. 

In the following scenario, a customer would like to 
open a new account with a bank advertising on the In- 
ternet. By using Interactive Home Banking prototype 

45 1300, the bank agent 1320 is able to collaborate and 
help the customer 1310 to fill in the application form 
1350, i.e. document 200, for a new account. 

A customer uses a personal computer 150 to con- 
nect'to the Internet 115 and runs a web browser (e.g. 

so Netscape Navigator) 1 30 to browse the home page of a 
bank called "Interactive Home Bank." After reading the 
information on the products offered by the bank, the cus- 
tomer 1310 desires to open a new account with this 
bank, and therefore makes a data connection with the 

55 bank agent 1 320 to establish a web collaboration ses- 
sion. 

To facilitate the discussion, a voice connection 1 365 
may also be established through the telephone network 
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1360 or other mechanisms. The voice connection can 
be made through a standard direct dial telephone con- 
nection or can be made through the Internet via tech- 
niques 1368 described in U.S. patent application 
number 08/595,897 to Hortensius et al. entitled s 
•Multipoint Simultaneous Voice and Data Services Us- 
ing a Media Splitter Gateway Architecture' filed on Feb- 
ruary 6, 1996 (EP-A-789470) . 

In the web collaboration session, when a new web 
document 1 350 is opened by one of the users (customer 10 
or bank agent), the same document will be displayed on 
the screen of another user. This sharing of browsing the 
web document 1 350 is supported by the CCI redirector, 
as described above. For example, if the bank agent 

1320 displays the application form 1.350, the customer is 
1310 will see the same form of his/her screen. By using 

the functionality of the message redirector, the key 
strokes typed by the customer for the account name will 
also appear in the corresponding account name field on 
the bank customer's screen. (Here the account name 20 

1 321 .comment 1 302, signature 1 303, submit 1 304, and 
clear 1 305 windows correspond to the child windows de- 
scribed in Figure 2). To facilitate the discussion, the cus- 
tomer 1310 and the bank agent 1320 may use the An- 
notation 1 42 and Remote Pointer 1 44 to mark and point 2S 

to the areas on the application form. With this prototype, 2. 
the customer and the bank agent can collaborate to- 
gether and share the web document and the input data 
to fill in a form for opening a new bank account. 

Many other applications are possible. For example, so 
the document 1 350 can be a contract, an order form, a 
menu, a design drawing, a listing of software code, a 
patent application, a bill of laden, or any other document 
1350/200 generally used in commerce. The agent 1320 
can be a sales person, a service provider (doctor, law- 35 
yer, accountant, etc.), designer (engineer, architect, pro- 
grammer), manager, etc. The customer 1310 can beany 
person that would use the goods and/or services pro- 
vided by the agent and/or any person the would work 
with (or for) the agent 1 320 using or producing the doc- 40 
ument 1350. There can be more than one agent 1320 
and/or more than one customer 1310. For example, the 
agent 1 320 can be a teacher that teaches more that one 
student (customer) 1310. The customers 1310 can be 
a plurality of people in a single or multiple companies *5 
"conferencing* with multiple supplier company person- 3. 
nel and/or consultants (agents) 1320. Pen based inter- 
faces permit all the collaborating parties to simultane- 
ously sign documents 200, e.g. contracts (like rental car 
agreements), credit card statements, using the Internet so 
without leaving their home or place of business. 

4. 



Claims 



.55 



A computer system (150A) having one or. more 
memories (175), one or more central processing 
units (1 70), one or more displays, one or more user 



input devices (1 90), an operating system (1 95), and 
a network interface (120) with a network protocol 
for communicating to a network (115), the network 
connected to one or more servers (110) and one or 
more shared computers (150B), the computer fur- 
ther comprising: 

a browser (130) for requesting one or more 
pages from one or more of the servers by send- 
ing one or more browser requests (132A) 
though the network interface and over the net- 
work to the server and the browser receiving 
from the server one or more of the requested 
pages sent over the network through the net- 
work interface; 

one or more redirectors (145, 155) capable of 
recreating as redirected browser requests one 
or more of the browser requests necessary to 
create a web page on the display; and 
a web sharing manager (160) connected to the 
network interface, for receiving the redirected 
browser requests, and for sending the redirect- 
ed browser requests over the network to one or 
more of the shared computers. 

The computer system of claim 1 , wherein the brows- 
er is capable of generating and processing one or 
more events and said operating system is capable 
of processing one or more messages, and said sys- 
tem further comprises a queue (165) for stacking 
one or more queued entries, one or more of the 
queued entries each containing one of the messag- 
es, and one or more ol the queued entries each con- 
taining one of the events; 

and wherein said one or more redirectors are 
capable of monitoring and recreating as redirected 
queued entries one or more of the queued entries, 
and said web sharing manager is capable of receiv- 
ing the redirected queued events from the redirector 
and incorporating each of the redirected queued 
events in a packet conforming to a network protocol 
which can be sent through the network interface 
and over the network to one or more of the shared 
computers. 

The computer system of claim 2, where one or more 
of the messages include any one of the following: 
an operating system message, an application mes- 
sage, a input device message, and a message pro- 
duced by one or more of the shared computers. 

The computer system of claim 3, where one or more 
of the messages are created by one or more of the 
following: keystrokes from a keyboard, mouse 
clicks and movements, pen input, speech signals 
from a speech recognition system, and operating 
system messages. 
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5. The computer system of claim 2, 3, or 4, where one 
or more of the events is a browser request. 

6. The computer system of any of claims 2 to 5, where 
one or more of the queued events are Common Cli- 
ent Interface (CCI) events created by the browser. 

7. The computer system of claim 6, where the CCI 
event is converted into an operating system proto- 
col, where the operating system protocol is Dynam- 
ic Data Exchange (DDE). 

8. The computer system of claim 6 or 7, where the CCI 
event includes any one or more of the following: a 
request for opening a page, a request to change a 
window size, a request to register a protocol, a re- 
quest to unregister a protocol, a request to get win- 
dow information, a request to be notified when a 
new page is open, and a request to be notified when 
a window size is changed. 



having a display, a network interlace (120) for com- 
municating toa network (115), anda browser (130) 
for sending requests for pages over the network and 
displaying the requested pages on the display, said 
s method including the steps of: 

retrieving a message (171) from a memory; 
duplicating the message if the message is nec- 
essary for a browser to create a page on the 

10 display; and 

sending the message over a network to a shar- 
ing computer (150B) so that a receiving brows- 
er on the sharing computer can use the mes- 
sage to create a received page on a received 

is display that is identical to the page. 



20 



9. The computer system of any of claims 2 to 9, where 
the sent packets (600) have a communication head- 
er (610) with information used by the network pro- 
tocol and one or more Web Sharing Manager Head- 25 
ers (620), each Web Sharing Manager Header hav- 
ing a Receiver ID field (622) and a Packet Length 
field (624), the former having a receiver value that 
identifies the redirector and the latter having a value 
specifying the length of Web Sharing Manager Data 30 
(630), the Web Sharing Manager Data having a Da- 
ta Type field (632) identifying the type of the event 
and a Parameter field (634) identifying the param- 
eters associated with the event. 

35 

10. The computer system of any preceding claim, 
wherein the browser is capable of displaying one or 
more of the requested pages on the display with one 
or more messages of information from the user in- 
put device; wherein said one or more redirectors are *o 
capable of recreating one or more of the messages 

as redirected messages; and wherein the web shar- 
ing manager is capable of receiving the redirected 
messages, and sending the redirected messages 
over the network to one or more of the shared com- 
puters, so that the shared computer displays a copy 
of the page on a shared display. 



11. The computer system of any preceding claim, 
where the server is an HTML server and one or so 
more of the pages is an HTML page. 

12. The computer system of any preceding claim, 
where the input device is a pen capable of produc- 
ing a signature and the document has one or more 55 
windows where the signature is placed. 

13. A method of operating a computer system (150A) 
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